The Session Initiation Protocol (SIP) has become a popular control protocol for many applications such as voice over internet (VoIP) and instant messaging (IM). These services are provided by SIP servers. Each of these sessions may have a different value to a service provider (operator), or a value with regard to service revenue or customer satisfaction. Overload is an inevitable condition for servers. Flash crowds, emergencies, and denial-of-service attacks can all initiate loads that exceed a server's resources. Therefore, servers should be designed with overload in mind. Given that a server cannot handle all of the requests it receives, it would be desirable for it to handle those requests which produce the most value for its operator. For example, “911” emergency calls should take precedence over other calls; text or picture messages may generate more revenue than local calls; and dropped calls are more frustrating for users than “system busy” messages. Furthermore, each operator may have different policies and values associated with each type of message.
SIP servers can become overloaded (server load exceeding its maximum capacity) despite being provisioned correctly. During overload, pending requests are dropped to decrease the server load and bring the load down to maximum server capacity. However, the indiscriminate dropping of requests can be costly because the requests dropped may have had a high value while those not dropped could have had a relatively low value. Clearly, under overload conditions, not all pending requests can be handled; therefore, the requests are to be prioritized. In prioritizing there is an additional component of servicing requests that should be considered, which is that the service delay could vary with the type of service request. In that case, it is not sufficient to handle the requests in terms of highest value first, and has to be a trade-off between delay and value.
Overload control can be implemented in multiple ways. Overload control in general entails dropping messages in order to reduce load. Clearly, message dropping needs to happen early in the processing path of a message to minimize the amount of processing (CPU, I/O etc) resources spent on a message that will ultimately be dropped. With that in mind, the different options for overload control are:
Support overload control at the network interface card (NIC) itself. While this allows a message to be dropped as early as possible, it requires additional processing support on a NIC.
Support overload control within the kernel. Overload control within the kernel eliminates the need for additional processing on the NIC, yet allows messages to be dropped before they are copied to the application, thus reducing the processing resources required compared to application-level support for overload control. Moreover, overload control within the kernel enables efficient layer-7 load balancing.
Require each application/proxy to support overload control. The drawback to this method is that by this time, the message has traversed a path from the NIC through the kernel to the application space, consuming processing (and host-NIC transfer) resources. This drawback is further exacerbated when using SIP software that runs on a Java Virtual Machine (e.g. SIP support on Websphere) since this involves additional execution path within the Java VM. The case for overload in this scenario arises when a proxy is supporting a large number of users, such as a VoIP service provider like Vonage, and clients come back up at roughly the same time after a regional loss of network connectivity (and thus requiring the clients to re-register).
Proxy-to-proxy interconnections. The more common case for overload control is for proxy-to-proxy interconnections. This is because proxies in the core of a service provider network, for example, will receive requests from proxies in other service providers, and this produces a much higher volume of requests than an access proxy which supports only user-agents and perhaps a connection to a few gateway proxies.
An SIP infrastructure may include user agents and a number of SIP servers, such as registration servers, location servers and SIP proxies deployed across a network. A user agent is an SIP endpoint that controls session setup and media transfer. All SIP messages are requests or responses. For example, INVITE is a request while “180 Ringing” or “200 OK” are responses. An SIP message may include a set of headers and values, all specified as strings, with a syntax similar to HTTP but much richer in variety, usage and semantics. For example, a header may occur multiple times, have a list of strings as its value, and a number of sub-headers, called parameters, each with an associated value. In the following example, Alice invites Bob to begin a dialog:
INVITE sip:bob@biloxi.com SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hMax-Forwards: 70To: Bob <sip:bob@biloxi.com>From: Alice <sip:alice@atlanta.com>;tag=192Call-ID: a84b4c76e66710@pc33.atlanta.comCSeq: 314159 INVITEContact: <sip:alice@pc33.atlanta.com>Content-Type: application/sdpContent-Length: 142(Alice's SDP not shown)
Setup sessions between user agents. (such as an INVITE) are routed by the proxy to the appropriate destination user agent based on the destination SIP URI included in the message. A session is set up between two user agents through an INVITE request, an OK response and an ACK to the response. The session is torn down through an exchange of BYE and OK messages.
SIP separates signaling from the media—signaling messages are carried via SIP, whereas media is typically carried as RTP (Real-time Transport Protocol) over UDP (User Datagram Protocol). Signaling messages are routed through the different SIP servers while the media path is end-to-end. The body of a session setup message (e.g., INVITE) describes the session using Session Description Protocol (SDP). The IP address and port numbers exchanged through SDP are used for the actual data transmission (media path) for the session. Any of these parameters can be changed during an ongoing session through a RE-INVITE message, which is identical to the INVITE message except that it occurs within an existing session. The RE-INVITE message is used most often in mobile networks to support handoff of an existing VoIP call due to user mobility (and subsequent change of endpoint addresses).
SIP messages primarily belong to three functional classes: (a) session setup/modification/teardown, (b) instant messaging and (c) event subscription/notification. RFC 3261 defines the basic set of messages and interactions that define sessions, such as REGISTER (for registering a user agent), INVITE, and ACK for session setup, BYE for session teardown, and a variety of other control messages such as OPTIONS. The MESSAGE request is an extension for ‘paging-mode’ instant messaging and the more recent, Message Session Relay Protocol (MSRP) defines methods for session-mode instant messaging. Another set of extensions, called SIMPLE, enable presence applications with the PUBLISH, SUBSCRIBE, and NOTIFY primitives for event notification.
SIP can operate over multiple transport protocols such as UDP, TCP (Transmission Control Protocol) or SCTP (Stream Control Transmission Protocol). Use of UDP is probably more prevalent today especially for proxy-to-proxy connections, but TCP usage is expected to grow. Additionally, when using TCP, SIP can use SSL (secure sockets layer) for security and encryption. It may also use IPSec underneath any of the transport protocols as well.
There is a need for a method and system to overcome the shortcomings of the prior art with respect to prioritizing service requests so that, under overload conditions, revenue is maximized by servicing the higher-value requests first.